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FOREWORD 


The  model  described  herein  was  developed  by  Calspan  Corporation 
(formerly  Cornell  Aeronautical  Laboratory,  Inc.)  as  one  task  of  its  System 
Engineering  Technical  Assistance  (SETA)  contract  with  the  AGM-86A  Program  Of- 
fice (RW  86)  of  the  Aeronautical  Systems  Division  (ASD)  of  the  Air  Force  Sys- 
tems Command  (AFSC) . The  model  was  defined  during  the  period  February  1972 
to  June  1972  under  Contract  No.  F33657-72-C-0228.  The  model  was  programmed 
and  implemented  on  the  IBM  370/165  computer,  located  at  Calspan,  Buffalo, 

New  York,  during  the  period  July  1972  to  September  1972  under  Contract  No. 
F33657-72-C-1013.  Initial  model  tests,  comprising  approximately  1300  test 
runs,  were  conducted  in  October  1972  and  reported  in  Calspan  Report  No. 
TA-5175-Q-11.' 


Maj.  J.  Hassell  of  the  Systems  Analysis  Division  (RW86S)  of  the 
AGM-86A  Program  Office  was  the  USAF  monitor  responsible  for  the  model  develop- 
ment. Threat  capabilities  and  characteristics  included  in  the  model  were  de- 
fined by  the  SCAD  Threat  Working  Group,  co-chaired  by  Mr.  W.  Cannon  (RW86S) 
and  Capt.  D.  Boyer  (Hq  SAC/XPHN) . Continuous  guidance  relative  to  threat 
modeling  data  was  provided  by  Maj.  R.  Harris  (Hq  SAC/INEP). 


Coordination  of  model  requirements  was  performed  by  A.  H.  Brown  and 
A.  Frueauf  of  the  Calspan  SCAD  SETA  Office  in  Dayton,  Ohio.  Design  and  de- 
velopment of  the  model  was  under  the  direction  of  Dr.  S.  Kaufman.  Major  con- 
tributors to  model  development  were  Messrs.  G.  Gaidasz,  R.  B.  Kruger,  R.  G. 
McLaughlin,  W.  Mensch,  N.  Morse,  J.  Persico,  P.  Przybylski,  R.  A.  Ratajczak, 
W.  F.  H.  Ring,  and  D.  Travnicek. 
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ABSTRACT 


The  model  described  in  this  report  was  developed  by  Calspan  Corpor- 
ation as  one  task  of  its  System  Engineering  Technical  Assistance  (SETA)  con- 
tract with  the  AGM-86A  Program  Office  (RW  86) . The  model  was  developed  on 
the  basis  of  an  AGM-86A  system  requirement  to  evaluate  SCAD  performance  capa- 
bilities in  a total  mission  environment.  The  model  (designated  SPEED  - Simu- 
lation of  Penetrators  Encountering  Extensive  Defenses)  complements  other  de- 
tailed engineering  models  available  within  the  SCAD  Program  Office  (PO) , 
thereby  providing  a broad  data  base  to  support  design  studies,  trade-off 
analysis,  and  risk  assessment. 

Some  of  the  effects  modeled  in  SPEED  are: 

• Penetrator  and  defense  attrition, 

• AWACS  (with  strobe-following), 

• Command  and  Control  System  netting, 

• Command  and  Control  delays, 

• Interceptor  and  SAM  Inventory, 

• Individual  interceptor  and  radar  characteristics, 

• Fratricide, 

• SRAMs  and  gravity  bombs, 

• Terrain  masking, 

• ECM  strobes  and  bumthrough, 

• SCAD  launch  and  in-flight  failures, 

• SCAD  navigation  errors, 

• SCAD  ECM  characteristics  and  ECM  Module  reliability,  and 

e SCAD  fuel  consumption. 

Model  output  data  includes  printouts  and  automatic  plots  of  detailed 
time  histories  and  statistical  summaries  for  a variety  of  measures  including 
number  of  bombers  surviving,  number  of  weapons  delivered,  number  of  encounter 
opportunities  against  penetrators,  and  detailed  offense-defense  interaction 
measures. 
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The  model  is  programmed  in  FORTRAN  IV  and  implemented  on  an  IBM 
370/165  computer.  The  model  uses  approximately  400  kilobytes  of  core  storage 
and  30-seconds  of  central  processor  time  to  simulate  a 5.5  hour  mission  in- 
volving up  to  100  penetrators  and  hundreds  of  defensive  elements. 

Three  separate  volumes  document  the  use  and  structure  of  the 
SPEED  model  in  different  levels  of  details.  The  three  volumes  are: 


Volume  1 - Overview,  in  which  the  essential  characteristics  of  SPEED 
I,  applicability  to  SCAD  engineering  development,  and 
directions  for  model  growth  are  described  (this  document)  , 

Volume  2 - Users'  Manual,  containing  an  expanded  functional  exposi- 
tion of  SPEED  I,  detailed  description  of  required  input 
data,  assumptions  made,  effects  modeled,  and  output  mea- 
sures provided.  Input  and  output  samples  are  included, 
and 

Volume  3 - Programmers'  Manual,  containing  source  program  listings, 

job  control  setup,  and  special  programming  considerations. 
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SECTION  I 


INTRODUCTION  AND  SUMMARY 


This  document  presents  an  overview  of  the  mode \j  developed  by  Calspan 
Corporation  for  the  AGM-86A  Program  Office^to  provide  a means  for  evaluating 
SCAD  performance  in  a total  mission  environment.  The  AGM-86A  System  Speci- 


fication contains  the  requirement  for  such  a model  to  be  used  in  the  course 
of  AGM-86A  System  development,  acquisition,  and  operation/employment  fort4* 


• the  timely  determination  of  quantitatively  optimal  values  of 

» 

System  and  Segment  performance  parameters,  and 


• the  comparative  evaluation  of  alternatives  and  change  proposals 
in  the  areas  of  design,  performance,  logistics  and  operations, 
tactics,  threats  and  scenarios,  as  applicable  throughout  the  life 
cycle  of  the  AGM-86A  System . 

The  model  was  defined,  implemented,  and  tested„as  one  task  of  the 
Calspan  Corporation  System  Engineering  Technical  Assistance  (SETA)  contract 
with  the  AGM-86A  Program  Office  (RW  86).  The  model  was  dVfined  in  detail 
during  the  period  February  to  June  1972,  was  implemented  obi  the  IBM  370/165 
computer  at  Calspan  Corporation,  Buffalo,  New  York,  duringythe  period  July 
to  September  1972,  and  initial  model  validation  and  sensitivity  tests  (ap- 
proximately 1300  test  runs)  were  performed  in  October  1972. 

Prior  to  model  definition,  a survey  was  made  of  existing  models  and 
simulations  to  determine  if  a model  existed  which  could  be  easily  adapted  to 
AGM-86A  requirements.  Some  of  the  required  model  characteristics  were: 

• fast  running  time, 

• ability  to  handle  large  scenarios, 

• ability  to  handle  individual  penetrator  flight  paths, 

• ability  to  accept  detailed  SCAD  engineering  data  inputs, 
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• compatibility  with  available  computer  facilities, 

• adaptable  to  AGM-86A  requirements  within  the  allocated  model  de- 
velopment schedule,  and 

• we 11 -documented. 

The  major  models  investigated  are  listed  in  Table  I.  It  was  determined  that 
none  of  these  models  were  completely  appropriate  for  the  stated  conditions. 

The  SPEED  model  was  therefore  developed  and  is  shown  pictorial ly  in 
Figure  1.  It  is  programmed  in  FORTRAN  IV  and  requires  approximately  400  kilo- 
bytes of  core  and  30-seconds  of  IBM  370/165  central  processor  time  to  simulate 
a 5.5  hour  mission  involving  hundreds  of  penetrators,  penetrator  weapons,  and 
defensive  elements.  In  one  of  the  scenarios  used  in  the  model  validation  tests, 
the  number  of  elements  considered  in  the  model  were: 

AWACS  - 1 
EW  Sites  - 119 
GCI  Sites  - 50 
SAMs  (5  types)  - 271 
Air  Bases  - 15 
AIs  (6  types)  - 271 

Penetrators  (bombers,  SCADs,  Hound  Dogs)  - 76 
Penetrator  Weapons  (SRAMs  and  Gravity  Bombs)  - 120 

Other  major  modeled  effects  and  elements  are: 

• penetrator  and  defense  attrition, 

• command  and  control  system  netting, 

• command  and  control  delays, 

• interceptor  and  SAM  inventory, 

• individual  interceptor  and  radar  characteristics, 

• fratricide, 

• terrain  masking. 
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• ECM  strobes  and  burnthrough, 

• AMACS  strobe  following, 

• SCAD  launch  and  in-flight  failures, 

• SCAD  navigation  errors, 

• SCAD  ECM  characteristics  and  ECM  module  failures,  and 

• SCAD  fuel  consumption. 

The  basic  approach  adopted  is  that  the  model  serves  as  a framework 
for  aggregating  and  integrating  detailed  one-on-one  or  localized  interaction 
results  introduced  as  input  look-up  tables  or  functions.  The  latter  are  de- 
rived from  prior  analyses  and  simulations,  using  real-time  manned  simulations 
where  appropriate.  In  this  way,  fairly  large  scenarios,  involving  individual 
trajectory  lay-downs  and  SCAD  vehicles  represented  in  substantial  engineering 
detail,  are  simulated  quickly  and  at  relatively  low  cost.  Model  operation 
involves  the  following  steps: 

• Preprocessing  of  input  data  on  penetrating  vehicles,  weapons, 
air  defense  system,  and  interaction  effects. 

e Generation  and  time-ordering  of  Primary  Events. 

• Sequential  simulation  of  all  events  - this  includes  generating 
Derived  Events  (which  along  with  primary  events  are  subsequently 
simulated  at  the  proper  time)  and  determine  the  interactive  con- 
sequences of  events;  the  latter  embodied  in  updated  State  Vectors 
for  penetrators  and  defense  elements. 

• Statistical  processing  and  summarization  of  data  outputs. 

The  model  is  a Monte  Carlo  model,  and  two-standard-deviation  confidence  intervals 
are  computed  within  the  model  for  the  major  test  measures.  Model  output  data 
includes  such  overall  mission  measures  as  bomber  survival  and  weapons  deliv- 
ered as  well  as  a variety  of  progressively  more  detailed  measures,  such  as 
number  of  AI  assignments,  encounters,  and  kills  against  each  type  of  penetra- 
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tor,  number  of  SAM  engagements  and  kills  against  each  type  of  penetrator,  and 
percent  of  time  the  defenses  are  saturated.  Both  computer  printouts  and  LDX 
plots  are  provided  for  both  detailed  time  histories  and  statistical  summary 
data.  In  addition  to  this  aggregate  data  for  each  set  of  replicates  a de- 
tailed event-by-event  output  listing  may  be  obtained  for  any  or  all  replicates 
as  a user  option. 


The  SPEED  model  was  initially  based  on  the  following  assumptions: 


preplanned  penetrator  flight  paths, 

constant  velocity  flight  path  segments,  instantaneous  turns, 
offense  weapons  produce  total  kill, 
no  bomber  navigation  errors, 

simplified  radar  cross  section  and  antenna  gain  tables, 
no  explicit  discrimination  of  decoys, 

AI  and  SAM  engagement  and  kill  probabilities  derived  from  more 
detailed  simulations  and/or  analyses, 

known  EOB  and  AOB  (portion  of  EOB  unknown  to  flight  path  planners), 
no  intercept  of  SRAM, 

AIs  are  reassignable  but  not  recycled, 

threat  characteristics  based  on  SCAD  threat  working  group  intelli- 
gence data, 
stationary  AWACS, 
present  bomber  ECM,  and 
main-lobe  jamming  only. 


A number  of  these  limiting  assumptions  will  be  eliminated  in  the  planned  modi- 
fications/expansions  to  be  incorporated  in  the  model.  The  planned  model  growth 
areas  are  described  in  detail  in  Section  IV  of  this  document. 

The  intent  of  this  document  is  to  provide  a full  description  of  the 
SPEED  I Model,  as  currently  configured,  along  with  a delineation  of  the  scope 
of  study  areas  to  which  it  may  be  applied.  Although  the  model  has  been  developed 
under  SCAD  Program  Office  sponsorship,  its  versatility  recommends  it  for  consid- 
eration by  other  programs  requiring  analysis  of  penetration  effectiveness. 
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SECTION  II 


SPEED  I MODEL  AND  COMPUTER  PROGRAM  DESCRIPTION 

2.1  OVERVIEW 

The  SCAD  SPEED  Model  concept  is  a stochastic,  event-based  simulation 
of  air  vehicles  (and  weapons)  penetrating  through  and  interacting  with  air  de- 
fense systems.  Penetrating  vehicles/weapons  encompass:  manned  aircraft, 

drones,  airborne  decoys,  and  various  air-launched  ordnance,  viz.,  ASM  and 
gravity  bombs.  Air  defense  systems  encompass:  area  defenses  (specifically, 

ground  EW  net,  AWACS,  airborne  interceptors  [AI],  airbases,  GCI  stations, 
along  with  the  integrating  CSC  structure),  and  point  defenses  (specifically 
SAM  sites  and  AAA  sites).  Weapon  targeting  can  include  air-defense  elements. 

2.1.1  Model  Approach 

The  model  is  stochastic  in  the  sense  that  many  factors  influencing 
the  course  of  events  are  represented  as  random  variables  sampled  in  accord- 
ance with  inputted  or  computed  probability  distributions.  It  is  event-based 
in  the  sense  that  the  simulation  sequences  from  key  event  to  next  key  event, 
hence  accepting  variable  intervals  between  simulation  steps. 

The  basic  approach  adopted  is  that  the  model  serves  as  a framework 
for  aggregating  and  integrating  detailed  one-on-one  or  localized  interaction 
results  introduced  as  input  look-up  tables  or  functions.  The  latter  are  de- 
rived from  prior  analyses  and  detailed  simulations  (using  real-time  manned 
simulations  where  appropriate).  In  this  way,  fairly  large  scenarios,  involv- 
ing individual  penetrator  trajectory  laydowns  and  offensive  and/or  defensive 
components  represented  in  substantial  engineering  detail,  can  be  simulated 
relatively  quickly  and  inexpensively. 
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Model  operation  involves  the  following  steps: 


• Preprocessing  of  input  data  on  penetrating  vehicles,  weapons,  air 
defense  system,  and  interaction  effects. 

• Generation  and  time-ordering  of  Primary  Events  (which  constitute 
a more  or  less  minimal  set  of  precomputable  events  necessary  to 
drive  the  total  simulation). 

• Sequential  simulation  of  all  events  - this  includes  generating 
Derived  Events  along  the  way  which  together  with  primary  events 
are  subsequently  simulated  (in  correct  time  order)  and  determin- 
ing the  interactive  consequences  of  events;  the  latter  are  em- 
bodied in  updated  State  Vectors  for  penetrators  and  defense  ele- 
ments. 

• Statistical  processing  and  summarization  of  data  outputs. 

2.1.2  Problem  Dimension  Capabilities 

Currently  allocated  storage  permits  representation  of  up  to  100  air- 
defense-system-  interacting  penetrators  of  three  different  classes  (e.g.,  air- 
craft, decoys,  long-range  ASM)  and  up  to  100  additional  penetrators/weapons 
of  two  different  classes  (e.g.,  small,  short-range  ASM,  and  gravity  bombs). 
Scenario  time  duration  is  currently  restricted  to  about  8.5  hours.  Scenario 
area  is  unlimited,  but  linear  dimensions  in  excess  of  2000  n.mi.  may  intro- 
duce distortions  of  ^ 2 percent  in  distances  between  points.  There  are  pro- 
visions for  up  to:  120  EW/GCI  radar  site  complexes  or  AWACS  (which  can  in- 

clude as  many  as  75  distinct  GC1/ACI  centers),  70  airbases,  200  simultaneously- 
in-f light  AI.  and  300  SAM  sites.  (Currently,  AAA  sites  are  excluded.)  The 
C6C  system  may  be  partitioned  into  as  many  as  five  air  defense  zones,  each 
represented  by  a zone  operations  center  (Z0C),  and  up  to  35  subcontrols  (i.e., 
intermediate  filter  centers  linking  EW  sites  to  ZOCs). 


Each  radar  site  complex  may  have  a complement  of  up  to  five  radars 
drawn  from  among  20  different  radar  types.  There  are  also  provisions  for 
eight  distinct  AI  types  and  eight  distinct  SAM  types. 

2.1.3  Summary  of  Model  Operation 

Penetrators  are  inputted  and  stored  as  pre-planned  flight  paths  con- 
sisting of  connected  constant-velocity  segments  in  three  dimensions  - start- 
ing at  launch  or  entry  into  the  simulated  area,  and  ending  at  DGZ  or  terminal 
point  or  exit  from  the  simulated  area.  (Ballistic  paths  may  be  approximated 
by  such  a series  of  straight  segments.)  One  type  of  penetrator  (identified 
as  the  SCAD  decoy  in  current  model  application)  has  its  flight  path  randomly 
deleted  or  perturbed  to  reflect  launch  failures,  navigation  errors,  and  in- 
flight vehicle  failures. 

The  initially  computed  Primary  Events  are  of  the  following  types: 

(1)  Penetrator  launch  or  entry  into  simulated  area 

(2)  Penetrator  check  point  (turn,  or  beginning  or  end  of  ascent 

or  descent  leg) 

(3)  Penetrator  terminal  point 

(a)  Pre-programmed  terminal  point  (i.e.,  weapon  DGZ,  final 
penetrator  checkpoint,  or  penetrator  exits  simulated  area) 

(b)  In-flight  failure  or  fuel-out 

(c)  Fratricide  (i.e.,  passage  of  penetrator  through  the  active 
zone  of  an  earlier  weapon  detonation) 

(4)  Change  in  penetrator  ECM  status 
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(5)  Penetrator  entry  into  EW/GCI  or  AWACS  visibility  zone  (i.e., 
unobstructed  radar  line-of-sight) 

(6)  Penetrator  exit  from  EW/GCI  or  AWACS  visibility  zone 

(7)  Penetrator  entry  into  SAM  visibility  and  weapon-capability  zone. 


Each  event  is  represented  by  the  following  data: 


• Event  type 

• Event  time* 

• Penetrator  identification* 

• Defense  entity  identification  (if  any) 

• Auxiliary  information  (depending  on  event  type) 

Figure  2 shows  an  illustrative  sequence  of  primary  events  (in  plan  view). 

The  numbers  in  parentheses  refer  to  the  primary  event  types  in  the  preceding 
list. 

Event  types  (1),  (2)  and  (3)  (initial  points,  check  points,  and 
terminal  points)  are  self-explanatory.  For  one  penetrator  class  (identified 
as  the  SCAD  decoy  in  current  application)  programmed  or  random  (failure) 
changes  in  ECM  status  are  carried  as  type  (4)  primary  events.  With  respect 
to  the  last  three  event  types,  EW/GCI  radar  sites  and  SAM  sites  have  indivi- 
dually inputted  maximum  terrain  mask  angles,  based  on  local  topography.  Ran- 
dom mask  angles  independently  and  uniformly  distributed  from  zero  to  maximum 
value  are  drawn  for  eight  principal  directions  of  each  site.  Penetrator  vis- 
ibility (line-of-sight)  as  a function  of  penetrator  altitude  is  then  deter- 
mined and  thereby  defines  (by  linear  interpolation)  "random"  octagonal  visi- 
bility zones  around  each  site.  For  SAM  sites,  these  zones  are  intersected 
with  (type-dependent)  maximum  missile  range  circles.  Although  SAM  exits  are 


* Penetrator  identification  and  event  time,  together  with  stored  penetrator 
flight  path,  serve  to  fix  location  of  event. 


Figure  2 SOME  PRIMARY  EVENTS  - IN  PLAN  VIEW 


not  explicitly  represented  as  events,  the  entry  events  carry  along  with  them 
time  duration  within  the  zone. 


Following  computation  and  time-ordering  of  all  primary  events,  the 
simulation  process  is  executed  as  a sequential  operation  on  all  events  in 
correct  order.  During  this  process  additional  or  Derived  Events  are  generated, 
and  these  are  of  the  following  types: 

1)  Penetrator  clear  detection  by  radar  site  subsequent  to  visibility 
zone  entry 

2)  Penetrator  strobe  bumthrough  by  radar  site  subsequent  to  visi- 
bility zone  entry 

3)  Initial  detection  report  by  EW  to  subcontrol 

4)  Strobe-to-bumthrough  detection  report  by  EW  to  subcontrol 

5)  Target  designation,  target  track  initiation  at  ZOC,  and  (pos- 
sible) AI  assignment 

6)  Reassessment  of  penetrator  target  track  for  subsequent  AI  assign- 
ment 

7)  Completion  of  penetrator  engagement  by  AI  and  assessment  of  con- 
sequences 

8)  Completion  of  penetrator  engagement  by  SAM  site  and  assessment 
of  consequences 

As  may  be  inferred  by  the  above,  superimposed  on  the  penetrator' s 
trajectory  sequence  (launch,  intermediate  check  points,  and  termination)  are 
two  major  interrelated  sets  of  sequences  - which  repeat  with  many  detailed 
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variations  - viz.,  (i)  EW  entry  (and  detection/bumthrough) , report  to  subcon- 
trol, target  designation,  AI  assignment,  AI  engagement  completed,  EW  exit  (and 
subsequent  break-track);  and  (ii)  SAM  entry  and  SAM  engagement  completed.  De- 
tailed discussion  of  the  simulation  process  is  deferred  until  paragraph  2.2. 

To  meet  current  model  application  requirements,  the  following  tabu- 
lar and  graphical  outputs  are  provided  on  completion  of  a replicated  SPEED  I 
run: 

1)  Penetrator  (bomber/ decoy)  attrition  data  and  summary  statistics 

2)  Distribution  of  decoy  ranges  flown 

3)  Time  histories  of  surviving  aircraft,  decoys  in  flight,  and 
weapons  delivered 

4)  Summary  statistics  on  AI  and  SAM  engagements,  conversions,  and 
kills  vs  bombers/decoys 

5)  Portion  of  time  spent  by  bomber/decoys  in:  no- interaction,  CSC 

delay,  system  saturation,  and  under-AI- engagement  states 

6)  Detailed  record  of  all  events  processed 

7)  Periodic  records,  during  the  simulation,  of  current  values  of 
selected  state  vectors  (optional). 

2.2  SPEED  I MODEL  DESCRIPTION 

Figure  3 shows  the  overall  flow  of  SPEED  I with  partitioning  of  the 
model  into  four  major  program  execution  steps. 
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Figure  3 SPEED  I MODEL  FLOW  DIAGRAM 
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PA0*  «AMUW)T  filmed 


2.2.1 


Overall  Simulation  Flow 


The  Preprocessing  and  Primary  Events  Generation  Step  (Step  1)  begins 
with  data  inputs  (from  punched  cards  and/or  disk  library)  describing:  pene- 

trator  flight  paths,  weapon  target  designations,  air  defense  system  composi- 
tion, and  interaction  tables.  Flight  paths  are  perturbed  or  deleted,  as 
previously  discussed,  and  random  terrain  mask  angles  computed  for  use  in  de- 
fining visibility  zones  around  EW  and  SAM  sites.  Inputs  are  also  processed 
to  meet  the  Simulation  Step  needs.  Following  this,  primary  events  are  gener- 
ated for  a given  replication.  It  should  be  noted  that  because  of  the  generally 
large  number  of  combinations  of  interacting  penetrators  and  EW  § SAM  sites, 
entry  and  exit  event  computations  are  often  a major  part  of  the  Step  1 run- 
ning time.  For  this  reason  much  care  was  taken  to  develop  a highly  efficient 
procedure  for  computing  visibility  zone  entries  and  exits.  Finally,  the 
primary  events  and  processed  data  are  outputted  for  use  in  subsequent  steps. 

A magnetic  tape  record  is  also  made  of  the  processed  data  outputs  (but  not  of 
the  primary  events  - which  are  as  yet  unordered  in  time).  This  procedure  is 
repeated  for  as  many  Step  1 replications  as  called  for  in  the  run  design. 

The  primary  events  are  fed  into  a System  370  Sort/Merge  program 
which  provides  an  event  sequence  output  ordered  by  replication  number  and, 
within  each  replication,  by  event  time.  A magnetic  tape  record  is  also  made 
of  the  ordered  primary  events. 

The  Simulation  Step  (Step  2)  may  follow  directly  from  the  above  Sort 
step  or  it  may  be  the  first  step  of  a separate  run  using  the  magnetic-tape- 
stored  primary  event  and  processed  input  data  generated  above.  The  rationale 
for  this  option  is  that  Step  1 is  the  most  expensive  step  and,  where  new  runs 
represent  only  parametric  variations  of  earlier  runs  that  do  not  alter  the 
primary  events,  the  earlier  computations  should  not  have  to  be  redone. 

Step  2 sequences  through  the  replications  set  up  by  Step  1.  Within 
each  replication,  the  processed  input  data  are  first  read  in  and  the  state 
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vectors  for  penetrators  and  defense  entities  initialized.  The  following  are 
the  major  components  of  penetrator  and  defense  entity  state  vectors. 

Penetrator* 

• General  status:  e.g.,  inflight-unengaged,  under  AI  engage- 

ment, killed  by  SAM  type  X,  etc. 

• State  of  ECM  modules:  off,  on,  or  failed  (per  module) 

• Index  of  engaging  AI 

• Index  of  controlling  GCI 

• Index  of  assigning  ZOC 

• Index  of  engaging  SAM  site 

• Time  of  exit  from  visibility  zone  of  controlling  GCI 
EW/GCI/AWACS  Site 

• Status:  operational,  destroyed 

• Numbers  of  detected  targets:  clear  detections,  strobes, 

bumthroughs 

• Numbers  of  reported  targets:  clear  detections,  strobes, 

bumthroughs 

Subcontrol 

• Numbers  of  current  target  reports:  clear  detections,  strobes, 

bumthroughs 

• Numbers  of  designated  targets  (established  tracks):  point 

targets,  triangulated  targets,  strobe  targets 

ZOC 

• Numbers  of  targets  in  track:  point,  triangulated,  strobe 

• Number  of  targets  under  AI  engagement 


* Stored  flight  paths  make  it  unnecessary  to  include  penetrator  position  as 
part  of  the  state  vector. 
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• Status:  operational,  destroyed 

• Number  of  vectoring  channels  in  use  (targets  toward  which 
AI  are  being  vectored) 

AI 

• Status:  on  CAP,  on  loiter,  engaging  penetrator,  expended* 

• Fuel  remaining 

• Last  reported  position  and  time 

• Projected  intercept  position  and  time 

Air  base 

• Status:  operational,  destroyed 

e Remaining  AI  inventory  (by  type) 

SAM  site 

e Status:  operational  and  number  of  targets  under  active 

engagement,  destroyed 
e Remaining  missile  inventory 

Penetrator  - EW/GCI/AWACS  site  interaction 

e Detection  status:  not  detected,  clear  detection,  strobe, 

burnthrough  - 6 reported  or  unreported 
to  subcontrol 

Penetrator  - Subcontrol  interaction 

e Number  of  point  detection  reports  on  penetrator  at  subcon- 
trol 


* AI  may  be  "expended”  either  by  having  used  up  its  AAM  load  or  by  reaching 
a point  where  it  has  only  sufficient  fuel  to  return  to  base. 


I 
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• Number  of  strobe  detection  reports  on  penetrator  at  subcon- 
trol 

• Target  track  status:  not  a target,  point  target,  triangu- 

lated target,  strobe  target 

Penetrator  - ZOC  interaction 

• Target  track  status:  not  a target,  point  target,  triangu- 

lated target,  strobe  target 

• Time  of  lost  contact  (for  radars  within  each  air  defense 
zone) 

• Time  of  penetrator  turn  following  lost  contact 

Penetrator  - GCI/AC1  interaction 

• Visibility  of  penetrator  to  each  GCI/ACI 

During  the  execution  of  Step  2,  derived  events  (see  paragraph  2.1.4) 
are  generated,  internally  stored  in  a Derived  Events  Array,  and  processed 
along  with  the  sequentially  inputted  primary  events.  The  procedure  followed 
by  Step  2 is:  to  have  read  in  at  any  moment  the  next,  as  yet  unprocessed, 
primary  event,  to  compare  it  with  the  earliest  derived  event  in  storage,  se- 
lect the  earlier  of  the  two  to  be  processed,  and  call  the  interaction  sub- 
routine corresponding  to  that  event  type.  There  are,  of  course,  provisions 
for  bypassing  the  processing  of  an  event  when  either  the  penetrator  ov  de- 
fense entity  (if  any)  involved  is  no  longer  operational. 

The  various  event  interaction  subroutines  will  be  summarized  in 
paragraph  2.2.3.  In  general,  they  compute  the  significant  (deterministic  and 
random)  consequences  of  the  event  in  question,  modify  state  vectors  accord- 
ingly, generate  and  store  new  derived  events,  occasionally  invalidate  a fu- 
ture event  (e.g.,  AI  engagement  completed)  for  which  an  updated  version  has 
just  been  introduced,  and  write  selected  results  for  output  processing. 
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On  return  to  the  main  Step  2 program,  the  cycle  of  earliest-event 
determination  and  processing  is  repeated  until  all  events  are  exhausted.  The 
program  then  sequences  to  the  next  replication  and  proceeds  as  above  until 
all  replications  are  completed. 

The  final  step  (Step  3)  accumulates  the  outputs  written  during  the 
Simulation  Step,  aggregates  them  appropriately,  and  computes  summary  statis- 
tics for  individual  replication  as  well  as  for  the  total  run.  Tabular  print- 
outs and  LDX  plots  are  produced  which  correspond  generally  to  the  output 
listing  noted  in  paragraph  2.2.  A more  detailed  discussion  of  outputs  will 
be  provided  in  paragraph  2.5. 

2.2.2  Illustrative  Sequence  of  Events 

In  order  to  provide  a more  concrete  understanding  of  how  the  SPEED 
Model  operates,  a short  illustrative  sequence  of  events  for  a single  pene- 
trator  is  presented  in  Figure  4 in  plan  view.  Decimal  notation  for  derived 
events  signifies  order  in  relation  to  primary  or  previously  generated  derived 
events . 


Upon  penetrator  entry  into  an  EW  radar  visibility  zone  (Event  1), 
the  model  establishes  that  the  penetrator  is  noise  jamming  at  the  relevant 
radar  bands  and  is  immediately  detectable  as  a strobe.  Two  derived  (future) 
events  are  generated:  1.1, Initial  Report  of  Strobe  to  Subcontrol  (in  accord- 

ance with  a radar- load-dependent  time  delay)  and  1.2,  Radar  Burnthrough  De- 
tection (based  on  achieving  a critical  S/J  ratio) . State  vectors  are  modi- 
fied to  reflect  change  in  detection  status  of  penetrator  and  load  on  EN  ra- 
dar site.  (In  the  interest  of  brevity  we  will  henceforth  not  explicitly  re- 
fer to  many  of  the  state  vector  changes  which  are  made  to  record  the  conse- 
quences of  events.) 

The  next  event  processed  is  1.1  and  this  generates  Event  1.11, 
Designation  by  Subcontrol,  again  based  on  a subcontrol  load-dependent  time 


delay.  On  the  assumption  that  this  is  the  only  strobe  report  to  that  subcon- 
trol, no  target  track  is  established,  and  no  further  derived  event  is  gener- 
ated. 


Event  1.2  is  next,  generating  1.21,  Strobe-to-Bumthrough  Report 
Change  to  Subcontrol,  which  in  turn  generates  1.22,  Designation  by  Subcontrol. 
The  consequence  of  Event  1.22,  in  view  of  the  burnthrough,  is  establishment 
of  a point  track,  transfer  of  this  track  to  ZOC,  and  finally  after  some  fur- 
ther time  delay,  the  assignment  of  an  AI  and  controlling  GCI  to  engage  the 
penetrator.  This  results  in  generation  of  Event  4.1,  AI  Engagement  Completed, 
computed  to  occur  at  the  time  and  place  of  vectored  course  intercept. 

An  EW/GCI  site  visibility  zone  is  next  entered  (Event  2)  - assume 
this  site  to  be  the  one  vectoring  the  AI  to  intercept  - and  this  triggers 
a series  of  events  more  or  less  like  that  of  1.1  - 1.11  - 1.2  - 1.21  - 1.22, 
which  we  disregard  in  this  brief  illustration.  Meanwhile,  Events  3 and  4, 
respectively,  EW  Radar  Exit  and  Penetrator  Turn,  are  processed.  The  latter 
causes  an  updating  of  AI  intercept  with  generation  of  a new  AI  Engagement 
Completed  Event  (4.2)  and  invalidation  of  Event  4.1. 

On  processing  of  Event  4.2,  it  is  determined  by  random  number  draws 
that  (for  example)  the  AI  was  successful  in  encountering  the  penetrator, 
i.e.,  it  converted  and  fired  its  AAM,  but  that  none  of  the  individual  missile 
shots  resulted  in  penetrator  kill.  (These  determinations  take  account  of 
many  factors,  including  type  and  altitude  of  penetrator,  employment  of  ECM, 
type  of  AI,  nature  of  target  track,  and  use  of  dead-reckoning  by  GCI.) 

The  penetrator  next  proceeds  to  exit  the  EW/GCI  radar  visibility 
zone  (Event  5),  suffers  a failure  in  one  of  its  ECM  modules  (Event  6),  and 
enters  the  visibility/missile  capability  zone  of  a SAM  site  (Event  7).  In 
Event  7 a SAM  Engagement  Completed  Event  (7.1)  is  generated  corresponding  to 
the  expected  time  of  penetrator  kill  by  a SAM  missile  given  that  the  pene- 
trator is  killed.  This  event  is  reached  next,  and  it  is  determined  by  a ran- 
dom number  draw  that  the  penetrator  is  indeed  killed.  The  penetrator  state 
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vector  is  changed  accordingly  and  future  events  involving  this  penetrator 
(Events  8 and  9)  are  not  processed. 

To  get  some  appreciation  for  the  coordinated  actions  of  netted  EW 
sites.  Subcontrols,  GCI,  and  ZOC  within  the  SPEED  Model,  the  reader  is  re- 
ferred to  Figure  5.  Here  the  effects  of  operator  attention  and  information 
transfer  time  delays,  strobe  triangulation,  target  designation,  AI  assign- 
ment, dead-reckoning,  and  break-track  unfold  for  a single  penetrator  during 
a portion  of  its  flight.  Note  in  this  illustration  that  strobe  reports  at 
subcontrol  establish  a triangulated  target  track  when  there  are  three  concur- 
rent strobes.  ZOC  target  track  status  on  a given  penetrator  is  set  at  the 
most  definitive  status  among  the  individual  subcontrols  netted  to  that  ZOC. 
AI/GCI  assignments  are  made  by  ZOC  on  establishment  of  track  or  following  un- 
successful engagement,  assuming  the  track  still  exists.  After  a period  of 
track  extrapolation  under  lost  contact,  the  track  is  deleted.  In  the  present 
illustration,  the  two  tracks,  separated  in  time,  are  not  necessarily  recog- 
nized as  coming  from  the  same  penetrator,  especially  if  there  had  been  an 
intervening  penetrator  turn.  Following  kill  by  the  third  AI,  the  penetrator 
is  deleted  from  further  simulation. 

2.2.3  Major  Event  Interactions 

The  following  paragraphs  outline  the  more  significant  effects  or 
interactions  computed  within  each  of  the  event  type  interaction  subroutines. 
Checks  on  operational  status  of  penetrator  and  defense  entities,  and  state 
vector  changes  which  accompany  event  processing  are  not  specifically  called 
out  in  most  cases.  For  additional  details  the  reader  is  referred  to  Volumes 
II  and  III  of  this  report. 

1)  Penetrator  Launch  or  Entry  into  Simulated  Area 

• Computations  for  this  event  are  generally  of  the  nature  of 
state  vector  changes,  e.g.,  penetrator  status  set  "to  in- 
flight, unengaged"  (or  "failed-at-launch,"  if  so  predeter- 
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ILLUSTRATIVE  COMMAND  ft  CONTROL  COORDINATION  (FOR  SINGLE  PENETRATOR) 


mined  during  Step  1),  and  number  of  unlaunched  penetrators 
in  aircraft  of  given  type  reduced  by  1. 

2)  Penetrator  Turn  Point 

• If  under  radar  contact  and  AI  engagement,  update  projected 
AI  intercept. 

3)  Penetrator  Terminal  Point 

• If  event  represents  weapon  delivery,  determine  EW/GCI/AWACS 
site,  airbase,  and/or  SAM  site  destroyed  (if  any) 

• If  destroyed  site  includes  GCI  center,  abort  all  AI  engage- 
ments under  its  control;  reassign  AI  and  GCI  against  "freed" 
penetrators  wherever  possible. 

• If  destroyed  entity  is  an  AWACS,  abort  all  AI  engagements 
under  its  control;  if  any  "freed"  penetrators  are  under  ground 
track,  attempt  new  assignments. 

• If  Airbase  is  destroyed,  remaining  ground  AI  inventory  is 
lost. 

• If  SAM  site  is  desi.r-'ved,  abort  all  engagements  in  progress. 

4)  Change  in  Penetrator  ECM  Status 

a This  causes  a simple  state  vector  change  which  is  relevant 
to  detection  computations  made  in  the  EW/GCI/AWACS  visibility 
zone  entry  event. 


5)  EW/GCI/AWACS  Visibility  Zone-Entry 

• Determine  if  detection  is  inmediate  and  whether  clear,  strobe, 
or  strobe-bumthrough. 

• Determine  possible  future  clear  detection  event. 

• Determine  possible  future  burnthrough  event. 

• If  site  has  EW  function,  determine  future  report  to  subcon- 
trol event. 


v'.'S.y 
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• If  AWACS,  determine  possible  direct  AI  assignment  and  conse- 
quent AI  engagement  completed  event. 

• If  radar  contact  has  been  re-established  following  an  unob- 
served penetrator  turn  (course  change)  and  penetrator  is  under 
AI  engagement,  update  projected  AI  intercept. 

6)  EW/GCI/AWACS  Visibility  Zone-Exit 

• Computations  for  this  event  are  generally  of  the  nature  of 
state  vector  changes;  e.g.,  if  penetrator  is  under  AI  engage- 
ment and  controlling  GCI  has  just  lost  coverage,  then  hand- 
over to  another  GCI  is  attempted  but,  if  not  possible,  time 
of  lost  GCI  contact  (start  of  dead-reckoning)  is  noted. 

’\ 

7)  SAM  Site  Visibility  S Capability  Zone-Entry 

• if  site  is  not  saturated  or  depleted  of  missiles,  then, 

taking  into  account  appropriate  delays  and  ECM  effects,  de- 
termine: maximum  possible  number  of  missile  salvos  fired 

(if  any),  associated  total  engagement  probability  of  kill, 
associated  expected  number  of  missiles  fired,  and  expected 
time  of  penetrator  kill,  given  kill.  The  last  is  used  to 
establish  a future  SAM  engagement  completed  event. 

8)  Delayed  Clear  Detection  by  EW/GCI/AWACS  Site 

• Essentially  the  same  as  5 above. 

9)  Delayed  Strobe  Bumthrough  by  EW/GCI/AWACS  Site 

• If  site  has  EW  function,  determine  future  strobe-to-bum- 
through  detection  report  to  subcontrol. 

10)  Initial  Detection  Report  to  Subcontrol 

• Compute  time  delay  at  subcontrol  and  accordingly  determine 
future  target  designation  event. 
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11)  Strobe-to-Bumthrough  Detection  Report  to  Subcontrol 

• Essentially  the  same  as  10  above. 

12)  Target  Designation 

• Determine  if  triggering  report  implies  the  initiation  of  a 
target  track  at  subcontrol  and  transfer  to  ZOC  (or  upgrading 
of  an  existing  track,  e.g.,  from  triangulated  track  to  point 
track) . 

• If  new  or  upgraded  track,  and  penetrator  is  not  currently 
under  AI  engagement,  attempt  to  assign  AI  and  controlling 
GCI.  If  assignment  possible,  record  projected  intercept 
point  and  establish  a future  AI  engagement  completed  event. 

• If  assignment  not  currently  possible,  establish  a future  AI 
assignment  reassessment  event. 

13)  Assignment  Reassessment 

• Test  for  possible  break-track  by  this  ZOC. 

• If  track  continued  and  currently  not  under  AI  engagement, 
attempt  to  assign  AI  and  controlling  GCI.  If  assignment 
possible,  record  projected  intercept  point  and  establish  a 
future  AI  engagement  completed  event. 

• If  assignment  not  currently  possible,  establish  a future  AI 
assignment  reassessment  event. 

14)  AI  Engagement  Completed 

• If  AI  on  strobe-following  intercept,  test  AI  fuel  and  abort 
if  insufficient. 

• Determine  by  random  number  draw  if  AI  encounters  penetrator 

(probability  of  encounter  is  influenced  by:  penetrator  type, 

altitude,  ECM,  interceptor  type,  ACI  or  GCI,  point  or  strobe- 
target  vectoring,  and  extent  of  terminal  dead-reckoning). 
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• If  successful  encounter,  determine  by  random  number  draw  if 
an  MM  fired  by  AI  kills  penetrator. 

• If  no  encounter  or  no  kill,  test  for  possible  break-track 
by  ZOC. 

• If  track  continued,  either  attempt  an  immediate  new  AI/GCI 
assignment  or  establish  a future  AI  assignment  reassessment 
event . 

15)  SAM  Engagement  Completed 

• Determine  by  random  number  draw  if  a SAM  kills  penetrator 
(probability  of  kill  was  computed  during  SAM  entry  event). 

Assumptions  and  Implicit  Doctrine 

In  previous  sections  various  idealizations,  assumptions,  and  doc- 
trinal choices  made  in  developing  the  SPEED  model  structure  have  been  iden- 
tified. In  this  section  these  factors  are  described  in  more  detail  to  pro- 
vide explicit  information  as  to  the  applicability  and  limitations  of  the 
SPEED  model. 

Penetration  and  Defense  Suppression 


Flight  paths:  preplanned,  uniform-velocity  straight-line  seg- 

ments (no  turn  radii,  no  extended  reactive  maneuvers). 

ECM:  preplanned,  modularized  barrage  noise  jamming  (and  optional 

cross  section  augmentation);  ERP  pre-adjustable  vs  each  defense 
radar  type. 

Radar  cross  section:  by  frequency  band  and  (five)  azimuthal  sectors. 

For  one  penetrator  class: • constant  failure  rates  for  each  of  various 
type  (launch,  inflight,  and  ECM  module)  failures. 

For  one  penetrator  class:  navigation  error  CEP  proportional  to 

range;  and  direction  of  error  uniformly  distributed,  but  fixed 
for  each  penetrator. 


• For  one  penetrator  class:  fuel  consumption  rate  specified  by 

speed,  altitude,  and  remaining  fuel. 

• Defense  suppression  modeled  by  lethality  circle  (as  a function 
of  weapon  and  target)  centered  at  DGZ,  i.e.,  no  damage  outside 
circle  and  assured  destruction  inside  circle.  It  is  assumed  that 
any  subcontrol  or  ZOC  suppression  would  be  counteracted  by  use 

of  redundant  back-up  sites. 

Detection  and  Early  Warning 

• Terrain  masking:  random  mask  angle  for  each  of  eight  principal 

directions  drawn  from  uniform  distribution  between  zero  and  maxi- 
mum mask  angle.  Latter  is  site  dependent.  Visibility  between 
principal  directions  by  linear  interpolation.  Obstructing  ter- 
rain is  assumed  to  be  always  between  target  and  radar. 

• Detection  range:  deterministic  detection  at  S/N  corresponding 

to  50  percent  single-scan  probability  of  detection.  If  jamming 
is  present  w "iin  any  of  the  site's  radar  bands,  then  strobe 
detection  occurs  on  condition  of  visibility.  Point  detection  is 
based  on  the  radar  at  site  with  highest  performance  for  the  given 
situation. 

• Average  time  delay  for  initial  detection  report  to  subcontrol  is 

dependent  on  nature  of  detection  and  instantaneous  target  load 
at  radar.  At  high  loads  p ‘rator  target  may  be  completely 

missed  by  the  time  penetn.  jxits  radar  visibility  zone. 

• AWACS  are  assumed  located  at  an  artificial  stationary  point 
rather  than  on  an  orbit.  The  radar  is  assumed  not  to  be  clutter- 
limited.  Handover  and  other  cooperative  interactions  with  the 
ground-based  air  defense  system  are  modeled  to  only  a limited 
degree . 


Target  Designation,  Discrimination,  and  Air  Defense  Assignment 


• Any  single  clear  or  burnthrough  target  detection  report  on  a 
penetrator  is  sufficient  to  initiate  a target  track  at  subcontrol. 

• Three  or  more  strobe  reports  concurrently  received  at  subcontrol 
on  a given  penetrator  permit  subcontrol  to  infer  a triangulated 
target  track. 

• Decoys  are  assumed  100  percent  credible,  i.e.,  there  is  currently 
no  provision  for  classification  of  target  track  by  the  defense 
according  to  apparent  penetrator  class  nor  any  logic  built  in  for 
differential  defense  response. 

• Average  time  delay  for  filtering  of  radar  returns  and  target 
designation  at  subcontrol,  and  track  transfer  to  ZOC,  is  depen- 
dent on  nature  of  subject  target  report  and  report  load  at  sub- 
control. 

• ZOC  makes  AI  assignment  based  on  the  criterion  of  earliest  pos- 
sible intercept  time.  Intercept  times  are  computed  by  a colli- 
sion course  model  (plus  a fixed  initial  time  delay,  and  in  the 
case  of  strobe-following  interceptions  a fixed  percentage  penalty). 
An  additional  requirement  is  that  there  must  be  a GCI  center  with 
open  vectoring  channel  within  nominal  (altitude-dependent)  radar 
visibility  range  of  the  predicted  intercept  point. 

• A proportion  of  AI  inventory  at  each  base  is  initially  airborne 
(on  CAP),  assignments  select  from  these  AI,  and  the  CAP  slots  are 
continually  replenished  until  ground  inventory  depletion. 

• A penetrator  will  not  be  engaged  by  two  or  more  AI  simultaneously. 

• Although  SAM  sites  should  be  realistically  viewed  as  under  the 
FCC,  and  ultimately,  ZOC  control,  it  is  assumed  because  of  the 
generally  localized  nature  of  penetrator  - SAM  interaction  that 
penetrator  entry  into  the  combined  zone  of  tracking  radar  visi- 
bility and  missile  range  capability  will  generally  trigger  an 
attempted  SAM  response  (unless  site  is  saturated  or  depleted  of 
missiles) . 
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• AWACS  can  initiate  its  own  AI  assignments,  using  accompanying 
CAP  presumably  under  ZOC  coordination,  but  still  circumventing 
much  of  the  CSC  delay  associated  with  ground-based  early  warning. 
It  requests  replenishment  from  a dedicated  air  base  inventory  as 
soon  as  an  assignment  is  made. 

• If  contact  with  tracked  penetrator  is  lost  by  all  sites  netted 
to  a given  ZOC,  then  track  is  maintained  by  extrapolation  for  a 
fixed  period  of  time  before  being  expunged. 

• Target  track  maintenance  at  a ZOC  is  assumed  to  be  independent 
of  status  at  other  ZOCs. 

AI  Engagement 

• If  a penetrator  being  engaged  by  an  AI  makes  an  observed  turn, 
then  a new  predicted  intercept  point  is  computed  and  the  AI 
flight  adjusted  accordingly.  If  the  result  of  the  turn  makes  in- 
terception impossible  (e.g.,  intercept  would  have  to  occur  out  of 
visible  range  to  any  GCI  center)  then  the  intercept  is  aborted 
and  the  AI  is  loitered  at  its  last  position. 

• The  end  game  is  represented  by  a sequence  of  two  steps:  (1)  the 

terminal  search,  detection,  lock-on,  and  conversion  into  firing 
position;  and  (2)  the  firing  of  AAM.  (This  sequence  could  typi- 
cally be  repeated  a second  time.)  Under  detailed  consideration 
of  AI  end  game  doctrine  and  tactics  for  various  AI  types  and  in- 
tercept altitudes,  it  is  possible  to  establish  two  probabilities: 
(1)  a probability  of  AI  successful  encounter,  i.e.,  probability 
that  the  AI  will  fire  at  least  one  AAM,  and  (2)  a conditional 
probability  of  kill  given  encounter.  These  two  probabilities 
are  in  turn  relatable  to  more  fundamental  quantities,  such  as: 
probability  of  being  successfully  vectored  to  within  detection 
range,  probability  of  conversion  for  frontal  attack,  probability 
of  conversion  for  rear  attack,  and  AAM  single-shot  probability 
of  kill.  In  summary,  then,  the  consequence  of  AI  intercept  is 
determined  by  comparison  of  random  draws  with  two  input  probabil- 
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ities  selected  in  accordance  with  the  specific  conditions  of  the 
intercept. 

Strobe-following  AI  intercept  assignments  are  made  without  any 
fuel  test.  Consequently,  such  an  intercept  may  at  times  be  a- 
borted  when  the  AI  reaches  its  "point  of  no  return"  for  getting 
back  to  base. 

AI  returning  to  base  are  not  recycled  within  the  current  version 
of  SPEED. 


SAM  Engagement 


I 


2.3 


• SAM  and  AI  engagements  of  a given  penetrator  may  overlap  - and  it 
is  assumed  that  there  are  no  interfering  effects. 

• The  maximum  number  of  missile  shots  is  estimated  from  considera- 
tion of:  time  within  visibility/missile  capability  zone  (ex- 

cluding dead- zone),  missile  salvo  fly-out  time  (including  inter- 
salvo delay),  missiles  per  salvo,  and  track  initiation  time. 

Input  tables  supply  the  probability  of  successful  track  initiation 
and  the  single-shot  probability  of  kill  in  accordance  with  the 
specific  conditions  of  the  engagement.  The  consequence  of  the 
SAM  engagement  is  then  determined,  from  a single  random  draw, 

as  either  penetrator  killed  or  penetrator  not  killed.  Site  mis- 
sile inventory  is  in  any  event  reduced  by  expected  number  of  ex- 
pended missiles. 

SPEED  I PROGRAM  STRUCTURE 


As  presently  configured  for  the  IBM  System  370/165  at  Calspan's 
Computer  Center,  SPEED  utilizes  nine  program  execution  steps  in  various  com- 
binations, identified  as: 


INPUT 
STEP  1 
TAPE  1 


JHW» 
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S0RT 
TAPE  2 
DUP 
STEP  2 
STEP  3 
PL0TS 

(Four  of  these  steps  have  already  been  noted  in  the  paragraph  2.2.1,  Discus- 
sion of  Overall  Model  Flow.) 

INPUT 


The  basic  function  of  INPUT  is  to  select  data  sets  from  permanent 
disk  storage  (DISK  LIBRARIAN),  make  changes  - either  permanent  or  temporary 
for  the  given  run,  introduce  additional  data  as  required  via  punched  cards 
(e.g.,  random  number  seed,  number  of  replications,  and  run  label),  and  there- 
by create  a complete  input  data  set  for  STEP  1.  Time  and  core  storage  utili- 
zation by  INPUT  is  relatively  insignificant. 

STEP  1 (Preprocessing) 

As  described  in  paragraph  2.2.1,  STEP  1 generates  the  replicated 
primary  events  and  processed  data  inputs  for  STEP  2.  Core  requirement  is 
approximately  300  K bytes  and  running  (CPU)  time  per  replication  has  ranged 
from  5 to  30  seconds  for  the  cases  treated  to  date. 

TAPE  1 

This  is  a minor  step  which  generates  a permanent  tape  file  of  the 
processed  data  sets  out  of  STEP  1,  when  such  is  required  for  parametric  var- 
iations. 
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S0RT 

As  previously  described,  S0RT  applies  a System  370  Sort/Merge  pro- 
gram to  order  the  primary  events  by  replication  number  and  by  time  within  each 
replication.  Core  requirement  is  modest  at  a little  over  100  K bytes,  with 
CPU  time  in  the  vicinity  of  .25  to  .5  second  per  replication. 

TAPE  2 

This  is  a minor  step  which  generates  a permanent  tape  file  of  the 
ordered  primary  events  data  set  out  of  S0RT,  when  such  is  required  for  para- 
metric variations. 

PUP 

DUP  creates  a specified  number  of  carbon  copies  (duplicates)  of  all, 
or  any  selected  subset  of,  STEP  1 output  replicates.  The  rationale  for  this 
procedure  is  that  because  random  effects  occur  in  both  STEP  1 and  STEP  2, 
with  the  former  more  expensive  to  run,  the  variance  of  output  measures  may 
be  minimized  (under  a total  running  time  constraint)  by  use  of  fewer  STEP  1 
replicates  each  of  which  is  passed  through  STEP  2 several  times.  About  350 
K bytes  of  core  are  used  and  CPU  time  is  roughly  2 seconds  per  output  dupli- 
cate. 

STEP  2 

As  described  in  paragraph  2.2.1,  STEP  2 is  the  main  simulation  step  - 
it  processes  all  primary  and  derived  events  in  sequence  and  accumulates  data 
on  output  measures.  Again,  about  350  K bytes  of  core  are  used  and  our  ex- 
perience with  respect  to  runs  processed  to  date  has  been  that  from  2 to  7 
seconds  of  (CPU)  running  time  is  expended  per  cycle  (i.e.,  for  each  dupli- 
cated replicate). 


STEP  3 


This  step  conducts  the  necessary  output  data  processing,  including 
statistical  mean  and  standard  deviation  calculations.  It  also  sets  up  the 
proper  data  set  for  automatic  (LDX)  plotting.  Core  storage  is  200  K bytes 
and  prorated  CPU  time  is  in  the  vicinity  of  0.5  second  per  cycle. 

PL0TS 


This  step  is  a standard  software  package  which  sorts  the  plot  data 
and  feeds  the  LDX  plotter  for  generation  of  the  desired  output  graphs.  Time 
and  core  storage  utilizations  by  PL0TS  are  relatively  insignificant. 

2.4  INPUT  DATA 

Inputs  to  the  SPEED  I Model  may  be  divided  into  three  functionally 
distinct  portions:  (1)  a small  number  of  job  option  controls,  print  controls, 

random  number  generator  seeds,  etc.  which  are  presented  in  card  form  at  the 
beginning  of  a run;  (2)  the  bulk  of  the  data,  which  are  categorized  into 
sixteen  data  sets  and  typically  are  pre-stored  in  a disk  library;  and  (3) 
some  data  which  are  built  into  subroutines  or  function  subprograms.  The 
latter  two  portions  of  the  input  data  are  discussed  below,  followed  by  a de- 
scription of  the  uses  of  various  input  data  types  within  SPEED  I. 

2.4.1  Data  Set  Classification  and  Elements 

Except  where  specifically  noted,  distances  are  in  meters,  velocities 
in  m/s,  times  in  seconds,  and  weights  in  lbs.  All  geographic  locations  are 
inputted  as  latitude-longitude,  but  are  transformed  early  to  X-Y  projections 
on  a tangent  plane  with  Y axis  oriented  North  and  X axis  East.  The  tangent 
point  is  provided  with  the  aforementioned  control  inputs. 
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Data  Set  1 - EK/GCI/AWACS  Radar  Sites 


I 
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Entry  for  each  site  (numbered  consecutively)  contains  the  following 
information : 

• Location. 

• Radar  complement  - provides  for  up  to  five  radars  of  different 
type;  current  provisions  permit  selection  from  among  20  radar 
types. 

• Function  - distinguishes  among  EW  only,  EW/GCI,  GCI  only,  and 
AWACS. 

• Associated  GCI/ACI  center  number  - GCI/ACI  centers  are  separately, 
consecutively  numbered.  When  association  is  from  EW  site  to 
GCI,  it  means  that  EW  site  can  effectively  extend  coverage  of 
that  GCI  center. 

• Number  of  subcontrol  to  which  site  is  netted. 

e Altitude  - currently  used  for  AWACS  only. 

e Maximum  mask  angle  - in  radians. 

• No-mask  index  for  each  of  eight  principal  directions  - indicates 
which  directions  (if  any)  are  known  to  have  an  unmasked  view, 
like  at  a seacoast  location.  This  index  thus  permits  maximum 
mask  angle  to  be  ignored  for  selected  directions. 

Data  Set  2 - Radar  Type 

Entry  for  each  radar  type  contains  the  following  information: 

• Associated  decoy  ECM  module  number  - also  implies  radar  band  or 
group  of  bands. 

• Maximum  (PRF- limited)  range,  in  n.mi. 

• Minimum  permissible  elevation  angle.  (Note  that  detection  and 
bumthrough  ranges  are  contained  in  Data  Set  11.) 
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Data  Set  3 - Subcontrol  Centers 


This  specifies,  for  each  subcontrol,  the  zone  operations  center 
(ZOC)  to  which  the  subcontrol  is  netted. 

Data  Set  4 - Zone  Operations  Center  (ZOC)  Characteristics 

• Maximum  permissible  gaps  in  radar  contact  for  track  continuity 

(a)  with  no  intervening  penetrator  turn, 

(b)  following  an  intervening  penetrator  turn. 

• Delays  from  establishment  of  target  track  on  penetrator  to 
start  of  AI  engagement  (i.e.,  assignment  of  GCI  and  interceptor 
made,  and  interceptor  on  its  way) 

(a)  under  GCI  control, 

(b)  under  AWACS/ACI  control. 

• Degrade  factors  in  probability  of  penetrator  encounter  by  vec- 
tored AI  for  engagements  under 

(a)  AWACS  control*, 

(b)  strobe-following  control*. 

Data  Set  5 - Air  Bases** 

Entry  for  each  base  contains  the  following  information: 

• Location. 

• ZOC  (possibly  more  than  one)  to  which  base  is  netted. 

• Initial  interceptor  inventory  by  AI  type  - on  ground  and  on  CAP. 


* Logically,  these  characteristics  belong  with  Data  Set  16. 

**  Includes  bases  which  function  strictly  as  AWACS  CAP  replenishment  facil 
ities  (may  coincide  with  other  air  bases).  The  numbering  system  dis- 
tinguishes these  special  bases. 
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Data  Set  6 - Interceptor  Types 


• Time  constants  and  17  of  exponential  degradation  in  probability 
of  encounter  under  dead-reckoning.  [Degradation  factor  is 

exp  ( - tj/fj  ■ *2^2^  where  t^  is  duration  of  terminal  dead-reckoned 
vectoring  and  t2  is  duration  of  terminal  dead-reckoned  vectoring 
following  unobserved  penetrator  turn.]* 

Entry  for  each  interceptor  type  contains  the  following  information: 

• Scramble  delay. 

• Combat  radius . 

• Rate  of  climb. 

• Cruise  speed. 

• Fuel  consumption,  climb. 

• Fuel  consumption,  cruise. 

• Fuel  consumption,  loiter/CAP. 

• Maximum  altitude. 

• Minimum  altitude. 

Data  Set  7 - GCI/ACI  Centers 

• Number  of  simultaneous  vectoring  channels  available,  as  a func- 
tion of  GCI/ACI  type. 

• Time  delay  before  reassigning  interceptor  after  penetrator  is 
not  encountered 

(a)  assuming  point  vectoring, 

(b)  assuming  strobe-following  vectoring. 


* Logically,  these  characteristics  belong  with  Data  Set  16. 
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Entry  for  each  GCI/ACI  center  contains: 


• Number  of  EW/GCI  site  with  which  center  is  colocated. 

• ZOC  (possibly  more  than  one)  to  which  center  is  netted. 

Data  Set  8 - SAM  Sites 

Entry  for  each  SAM  site  contains: 

• Location. 

• Type  identification  - provision  for  up  to  eight  types. 

• Maximum  mask  angle  - in  radians. 

• No-mask  index  for  each  of  eight  principal  directions  (cf.  Data 
Set  1). 

Data  Set  9 - SAM  Types 

Entry  for  each  SAM  type  contains  the  following  information: 

• Identification  of  target  tracking  radar  (TTR)  type  (as  per  Data 
Set  2). 

• Minimum  time  delay  from  initial  detection  by  TTR  to  first  possible 
missile  launch. 

• Number  of  targets  that  can  be  simultaneously  engaged. 

• Initial  missile  inventory  assumed  for  all  sites  of  given  type. 

• Salvo  flyout  time  to  maximum  range  interception. 

• Number  of  missiles  per  salvo. 

e Maximum  interception  range  (missile/guidance  limited). 

• Minimum  interception  range  (radius  of  dead  zone). 

e ECM  degrade  factor  - associated  with  initiation  and  maintenance 
of  track. 

• Aggregated  probability  of  track  initiation/maintenance,  by  pene- 
trator  type  and  altitude  regime. 
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• Aggregated  single  shot  probability  of  kill  given  launch,  by  pene 
trator  type  and  altitude  regime. 

Data  Set  10  - DGZs 

Entry  for  each  DGZ  contains  the  following  information: 

• Location. 

• Identification  numbers  of  EW/GCI  sites,  air  bases,  and/or  SAM 
sites  (if  any)  at  DGZ  or  colaterally  located  within  a specified 
radius. 


Data  Set  11  - Detection  and  Bumthrough  Range  Table 


This  table  contains  aggregated  clear  detection  and  bumthrough 
ranges  of  each  of  the  radar  types  introduced  in  Data  Set  2 vs  each  penetra- 
tor  type  with  specified  ECM  configuration*  for  five  separate  azimuth  angle 
aspect  intervals.  The  criterion  used  in  calculation  was  50  percent  single- 
scan probability  of  detection.  Azimuth  angle  intervals  were  selected  to 
best  represent  major  changes  in  magnitude. 

Data  Set  12  - Bomber  Flight  Paths  and  Launches 

Entry  for  each  bomber  contains  the  following  information: 

• Number  of  check  points  in  bomber  flight  path  (a  check  point  can 
represent  a trajectory  turn,  initiation  or  termination  of  alti- 
tude change,  or  a weapon/decoy  release  point). 


* Effective  radiated  power  densities  as  well  as  antenna  gain  patterns  were 
taken  into  account.  Decoy  in  cross  section  augmented  and  unaugmented 
modes  appear  as  distinct  penetrator  types  in  the  table. 


t 


Data 


** 


e Number  of  planned  launches. 

e Group  or  wave  number,  if  any. 

• ECM  indicator  - currently  used  in  "all  ECM  on"  mode  only. 

• For  each  check  point:  location,  time*,  altitude,  speed,  from 

this  check  point  to  next. 

• For  each  planned  launch:  vehicle  type  (4  types  currently  pos- 
sible, including  decoys),  bomber  check  point  at  which  vehicle 
is  launched,  DGZ  number  of  target  (if  any). 

Set  13  - Decoy  Data** 

• Probability  of  launch  failure. 

• Mean  time  between  failures  (MTBF)  for  air  vehicle  failures. 

• MTBFs  for  failures  in  each  decoy  module. 

• Navigation/guidance  system  positional  error  coefficient  - cur- 
rently CEP  as  a fraction  of  cumulative  range  flown. 

• Initial  off /on  condition  for  each  ECM  module. 

Entry  for  each  decoy  vehicle  contains  the  following  information: 

• Identification  of  launching  parent,  targeted  DGZ  (if  any),  gross 
weight  (lbs),  decoy  configuration  designation,  initial  fuel  (lbs), 
and  number  of  check  points  in  decoy  flight  path. 

• At  each  check  point  of  the  nominal  (i.e.,  error-free)  decoy  flight 

path:  location,  time*,  altitude,  speed  from  this  check  point  to 

the  next. 


Times  beyond  the  first  check  point  are  redundant  with  speed  and  are  used 
only  as  a partial  check  on  accuracy  of  mission  flight  path  planning. 

Excluding  fuel  rates  which  are  in  next  data  set. 
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Data  Set  14  - SCAD  Fuel  Rate  Table 


This  table  contains  averaged  SCAD  fuel  consumption  rates,  in  lbs/ 
sec,  for  various  combinations  of  SCAD  speed,  altitude,  and  gross  weight  (from 
full  load  to  fuel  out).  Additional  tables  provide  for  design  variants,  e.g., 
armed  SCAD. 

Data  Set  IS  - Weapon  Data 

• Delay-to-function-time  (from  launch). 

• Fratricide  radii  of  weapons  vs  penetrators*. 

• Fratricide  active  times  of  weapons  vs  penetrators*. 

• As  an  alternate  to  delay-to-function-time,  the  average  speed  of 
weapon  along  an  assumed  straight  line  trajectory  from  launch  to 
DGZ. 

Data  Set  16  - AI  Effectiveness  Data 

This  data  set  contains  tables  of  basic  aggregated  probabilities  of 
encounter,  and  aggregated  probabilities  of  kill  given  encounter,  by  airborne 
interceptors  of  different  type  vs  penetrators  of  different  types  at  low  and 
at  high  altitudes.  It  should  be  recalled  that  probability  of  encounter  may 
be  degraded  by  factors  associated  with  AWACS  control  or  strobe-following  (see 
Data  Set  4)  or  with  dead-reckoning  time  (see  Data  Set  6) . 

2.4.2  Inputs  Within  Subroutines  or  Function  Subprograms 

Data  are  used  at  several  points  in  the  SPEED  I model  which  are  ef- 
fectively inputs,  but  which  either  were  built  into  the  program  logic  itself, 
or  were  input  by  means  of  function  subprograms.  These  are  not  immutable 


* Model  assumes  fratricide  if  penetrator  is  within  radius  during  any  portion 
of  the  active  time. 
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features;  in  fact  any  of  these  might  appear  as  explicit  inputs  in  future  ver- 
sions of  the  SPEED  model.  The  items  include: 

• Time  delay  between  detection  at  the  radar  site  and  receipt  of  the 
corresponding  report  at  the  subcontrol;  this  is  a function  of 
workload  at  the  site  and  type  of  target  (strobe,  bumthrough, 
clear) . 

• Time  delay  between  receipt  of  a report  at  the  subcontrol  and  re- 
ceipt of  a target  track  at  the  zone  operations  center;  this  is 

a function  of  workload  at  the  subcontrol  and  the  type  of  report 
(strobe,  burnthrough,  clear). 

• Nominal  coverage  range  of  GCIs  as  a function  of  penetrator  alti- 
tude. A GCI  must  be  found  within  nominal  range  of  the  projected 
intercept  point  before  interceptor  assignment  can  be  made. 

• Loiter/CAP  altitude  (and,  implicitly,  cruise  altitude  for  low 
altitude  intercepts.  Note  that  the  model  does  not  explicitly 
fly  interceptor  flight  paths).  Currently,  a single  altitude  is 
used  for  all  loitering  and  CAP  interceptors,  regardless  of  type. 

2.4.3  Uses  of  Specific  Inputs  in  the  SPEED  I Model 

Figures  6 and  7 depict  functions  performed  within  Step  1 and  Step  2, 
respectively,  of  the  SPEED  I Model,  and  some  of  the  interrelationships  among 
those  functions.  At  the  left  of  each  of  these  diagrams,  the  list  of  input 
items  is  given,  and  the  relationship  of  each  to  the  various  functions  within 
the  model  is  indicated.  The  result  is  a simplified  representation  of  the 
contribution  of  each  specific  input  item  to  the  functioning  of  the  model. 

Each  function  of  Step  2 is  linked  to  functions  not  represented  here 
which  produce  SPEED  I outputs.  The  intricacies  of  output  production  are  be- 
yond the  scope  of  this  summary  report,  and  hence  these  diagrams  make  no  ex- 
plicit reference  to  output  functions  or  the  details  of  Step  3 of  the  model. 
The  outputs  themselves  are  described  in  paragraph  2.5. 
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Figure  6 SPEED  I MODEL-STEP  1 

INPUT  DATA  UTILIZATION 
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NETRATOR  TRAJECTORY  DATA 


Figure  7 SPEED  I MODEL  - STEP  2 INPUT  DATA  UTILIZATION 


Figure  6 emphasizes  the  major  functions  of  Step  1,  Preprocessing  and 
Primary  Events  Generation.  These  are: 

• Conversion  of  all  location  data  to  Cartesian  coordinates. 

• Perturbation  of  decoy  flight  paths  to  simulate  navigational  errors. 

• Monte  Carlo  determination  of  mask  angles  surrounding  EW  and  SAM 
sites  to  simulate  terrain  effects. 

• Monte  Carlo  determination  of  decoy  launch  failures,  in-flight 
failures  and  ECM  module  failures. 

• Calculation  of  cumulative  fuel  consumption  at  each  check  point 
of  the  decoy  flight  paths. 

• Calculation  of  penetrator  fratricides. 

• Provision  of  the  primary  events  listed  in  paragraph  2.1.4. 

• Reformatting  (wherever  necessary)  and  transfer  of  input  data,  not 
otherwise  required  in  Step  1,  to  the  simulation  step.  (Includes 
performing  the  transformation  to  Cartesian  coordinates  in  the 
case  of  all  location  data.) 

The  right  hand  end  of  the  figure  gives  the  various  Primary  Event  types  gener- 
ated for  use  in  Step  2.  It  will  be  remembered  from  Figure  3 that  the  primary 
events  are  passed  to  STEP  2 as  one  data  set  either  on  magnetic  tape  or  disk, 
while  the  remainder  of  the  data  are  similarly  passed  as  a second  data  set. 

Using  Figure  6,  a specific  Primary  Event  type  passed  to  Step  2 can 
be  traced  backwards  to  find  the  input  data  used  in  generating  events  of  that 
type.  For  example,  the  event  marking  the  launch  of  a decoy  is  based  on  the 
set  of  perturbed  decoy  check  points  (with  launch  failures  indicated)  which 
depends  in  part  upon  the  probability  of  launch  failure  and  the  time  of  the 
first  check  point  of  the  decoy  flight  path.  As  with  all  location  data,  the 
launch  event  location  makes  use  of  the  target  point  through  the  transforma- 
tion from  latitude  and  longitude  to  Cartesian  coordinates. 
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The  descriptive  titles  appearing  at  the  left  of  Figure  6 in  some 
cases  are  not  individual  items  of  data  but  represent  several  data  items  which 
are  related  in  application  within  the  model.  To  the  left  of  each  box,  the 
data  set  number,  as  defined  in  paragraph  2.4.1,  which  contains  the  items 
in  the  box  is  given. 

Figure  7 is  a similar  diagram  relating  input  data  items  to  the  func- 
tions performed  in  the  simulation  step.  In  this  case,  the  primary  events 
generated  in  Step  1 are  included  along  with  the  other  data,  both  to  emphasize 
their  crucial  role  in  SPEED  I operation  and  to  illustrate  the  relationship 
with  Step  1 functioning.  The  functions  depicted  are  for  a typical  penetrator, 
which  in  the  diagram  is  assumed  to  go  through  an  entire  detect-track-assign- 
engage  sequence  by  interceptors,  followed  by  loss  of  coverage  by  EW/GCI  radars, 
by  SAM  encounter,  by  weapon  launch/drop  and  by  termination  in  that  order.  It 
must  be  remembered  that  individual  penetrators  do  not  necessarily  experience 
this  particular  sequence,  since  the  functions  of  Step  2 occur  in  the  order 
dictated  by  the  timing  of  the  events  in  the  simulation.  Thus,  for  example, 
there  may  be  SAM  engagements  before  or  concurrent  with  the  interceptor  command 
and  control  sequence,  the  weapon  launches  may  be  interspersed  among  the  other 
events,  loss  of  EW  radar  coverage  may  occur  before  the  interceptor  engagement 
is  over,  or  there  may  be  more  than  one  interceptor  assignment  cycle  experi- 
enced. If  any  of  the  engagements  should  result  in  a kill  of  the  penetrator, 
subsequent  events  relating  to  that  penetrator  are  bypassed. 

2.5  SPEED  I OUTPUTS 

2.5.1  Detailed  Simulation  History 

Figure  8 is  a sample  page  of  printout  that  summarizes  the  history 
of  processed  events  and  consequences.  The  user  can  request  such  printout  for 
any  subset  of  the  Step  2 simulation  cycles. 
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Figure  8 STEP  2 SIMULATION  HISTORY 


The  left -most  literal  entry  plus  the  nine  adjacent  columns  describe 
the  event  processed,  the  numerical  entries  representing,  respectively:  pene- 

trator  index,  time  (seconds),  event  type,  defense  entity  index,  defense  enti- 
ty type,  penetrator  type,  and  three  additional  quantities  of  variable  defini- 
tion. Thus,  for  example,  EW  ZONE  ENTRY  EVENT,  designated  by  an  asterisk  on 
the  far  left,  involves  penetrator  number  18  entering  radar  site  number  23  at 
time  7917.  The  "1"  signifies  that  the  defense  entity  is  in  fact  an  EW/GCI/ 
AWACS  site  and  the  "2"  that  the  penetrator  is  one  of  that  designated  class. 

The  "269"  is  the  calculated  exposure  time,  i.e.,  the  penetrator  will  exit  the 
visibility  zone  269  seconds  later. 

The  literal  entry  positioned  roughly  at  the  center  of  the  page  plus 
the  nine  adjacent  columns  to  the  right  describe  the  additional  derived  event (s) 
generated  by  the  event  in  process  at  the  time  (and  which  will  subsequently 
be  processed  at  the  proper  sequence  in  the  simulation) . Referring  again  to 
the  asterisked  line,  we  observe  that  both  an  AI  ENGAGEMENT  COMPLETED  and  an 
EW  REPORT  TO  SUBCONTROL  are  generated.  The  latter  is,  of  course,  what  one 
would  expect.  Note  that  this  event  is  predicted  to  occur  at  time  7953,  or 
36  seconds  later.  The  "7"  identifies  the  subcontrol  to  which  the  report  is 
made.  Also,  the  "BURNTHROUGH"  entry  at  the  far  right  signifies  that  the 
nature  of  the  detection  was  that  of  an  immediate  burnthrough  of  a jamming 
strobe. 


The  explanation  for  the  new  AI  ENGAGEMENT  COMPLETED  event  is  that 
penetrator  No.  18  is  currently  under  AI  engagement  (AI  number  25),  had  pre- 
viously made  an  unobserved  turn  (so  that  the  AI  was  still  being  vectored  to 
an  intercept  based  on  the  old  penetrator  track) , and  the  current  EW  entry 
permitted  the  track  to  be  updated  and  AI  to  be  revectored.  Engagement  is  pre- 
dicted to  occur  at  a revised  location  and  time  and,  thus,  needs  to  be  re- 
corded as  a new  event.  The  "2"  and  "5"  in  columns  7 and  8 refer,  respective- 
ly, to  the  identity  of  the  controlling  ZOC  end  to  a matching  number  that  al- 
lows the  model  to  reject  the  prior  AI  ENGAGEMENT  COMPLETED  event  which  has 
now  been  replaced. 
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Figure  9 is  a composite  of  portions  of  several  pages  of  printout 
which  periodically  summarizes  the  offensive  and  defensive  state  vectors  dur- 
ing Step  2 simulation,  again,  printed  at  the  option  of  the  user.  The  PENE- 
TRATORS  block  covers  such  items  as  general  status  (LSTAT,  LTAG) , identity  of 
engaging  AI  and  controlling  GCI  (IAS,  IKS),  target  status  at  ZOCs  (JTRDIZ), 
time  of  last  contact  on  tracked  penetrators  (LOSCON)  and  numbers  of  penetra- 
tors/weapons  of  different  classes  that  remain  to  be  launched  (LUNL) . The 
ZONAL  OPERATIONS  CENTERS  and  AWACS  blocks  provide  data  on  numbers  of  target 
tracks  (or  detections)  of  different  categories.  The  INTERCEPTORS  block  deals 
with  Al  currently  in  flight  and  includes:  last  recorded  position/time  (XXL, 

YYL,  ZZL,  ITIML) , projected  intercept  point,  if  any,  (XXI,  YYI,  ZZI,  ITIMI), 
remaining  fuel  (RIFUEL),  interceptor  type  (I ID),  and  whether  on  CAP,  loitering 
or  engaging  (ISTAT),  The  AIRBASES  and  SAM  SITES  blocks  note  operational 
status  and  remaining  ground  AI  or  missile  inventory,  the  former  by  AI  type. 

2.5.2  Accumulated  and  Statistical  Outputs 

These  outputs,  in  the  form  of  tabulations  and  graphs,  are  illustrated 
in  Figures  10  through  17.  Since  the  main  purpose  here  is  to  familiarize  the 
reader  with  the  forms  as  currently  provided,  and  not  to  attempt  any  in-depth 
analysis  of  results,  the  outputs  displayed  have  been  taken  from  several  un- 
related runs. 

In  Figure  10  the  first  two  lines  display  the  aggregated  time  (in 
seconds)  spent  by  two  kinds  of  penetrators  (B-52,  SCAD)  in  various  conditions 
relative  to  the  AI  defense  process,  shown  in  Figure  10A  during  a single  cycle 
(replication).  "NO  INTERACTION"  denotes  the  condition  of:  not  currently 

detected,  not  an  extrapolated  target  track,  and  not  under  engagement  by  a 
vectored  Al.  "CSC  SYSTEM  DELAYS"  denotes  the  condition  of  having  been  de- 
tected but  not  having  reached  the  point  in  information  processing  and  trans- 
fer where  a ZOC  (or  AWACS)  is  ready  to  attempt  an  AI  assignment.  The  next 
three  columns  refer  to  saturation  conditions  under  which  an  assigning  center 
is  prevented  from  following  through  against  the  penetrator  in  question  be- 
cause of  some  resource  limitation.  "AI  ENGAGING"  clearly  means  that  the  pene- 
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trator  is  under  enegagement  by  a vectored  AI.  The  six  conditions  covered 
add  up  to  the  "TOTAL  TIME."  "BLIND  TIME"  is  an  additional  classification 
overlapping  with  the  previous  conditions.  Time  measurements  on  a penetrator 
are  accumulated  only  following  initial  detection  by  some  radar.  The  next 
two  lines  in  the  figure  transform  the  results  to  percentage  of  TOTAL  TIME. 

The  bottom  portion  of  the  figure  presents  the  mean  estimate  and  the  mean  i 
two  standard  deviations  of  this  estimate  for  each  percentage  measure  taken 
over  all  replications. 

Figure  11  displays  all  of  the  "unnatural"  terminations  for  each  of 
two  classes  of  penetrators  within  a single  replication.  For  each  such  ter- 
mination the  time,  cause,  coordinates,  and  accumulated  range  flown  are  given. 
When  the  cause  is  AI  or  SAM  kill,  the  Al  or  SAM  type  is  noted.  "LAUN"  sig- 
nifies a failure  at  launch.  "UNLA"  signifies  that  penetrator  was  unlaunched 
because  parent  aircraft  had  previously  been  killed. 

Figures  12  and  13  are  reasonably  self-explanatory.  Since  the  dis- 
tribution and  time  histories  are  averaged  over  all  replications,  the  mean 
estimates  are  accompanied  by  * two  standard  deviation  bounds  about  these  esti- 
mates. 

Figure  14  summarizes  the  attrition  measures  for  penetrator  types 
over  all  replications.  Again,  kills  by  AI  and  SAM  entities  are  subdivided  by 
type.  The  entries  are  estimated  mean  numbers  of  penetrators  of  each  class 
terminated  by  the  specific  mechanisms,  along  with  t two  standard  deviation 
bounds  about  these  estimates.  The  mechanism  "CLOBBER"  refers  to  inflight 
failure;  the  term  comes  from  one  possible  source  for  inflight  failure;  namely, 
a malfunction  of  the  automatic  terrain  avoidance  system  resulting  in  ground 
impact. 

Figure  15  provides  a further  analysis  of  the  AI  and  SAM  engagement 
process  by  estimating  mean  numbers  of  AI  assignments,  AI  encounters,  AI  kills, 
SAM  engagements,  and  SAM  kills.  (See  paragraph  2.3.4  for  clarification  of 
these  terms.)  The  P(*/0  entries  refer  to  estimates  of  various  conditional 


probabilities  for  the  particular  conditions  of  the  simulated  scenario,  the 
mix  of  AI  and  SAM  types,  and  the  penetration  altitudes  actually  realized. 

Figures  16  and  17  illustrate  some  of  the  automatic  LDX  plots  that 
are  provided  as  adjuncts  to  the  tabular  outputs. 
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Figure  13  TIME  HISTORY  OF  SELECTED  MEASURES 
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Figure  IS  STATISTICS  OF  ASSIGNMENTS,  ENCOUNTERS,  ENGAGEMENTS,  AND  KILLS 


SECTION  III 


SPEED  APPLICATIONS 

The  SPEED  Model  has  the  capability  to  provide  traceability  of  vari- 
ations in  penetration  effectiveness  relative  to  variations  in  SCAD  design. 

The  model  outputs  vary  at  the  user's  option  from  such  overall  mission  mea- 
sures as  bomber  survivability  and  weapons  delivered  to  extremely  detailed 
outputs  such  as  a record  of  each  event  as  it  occurred  during  the  simulation. 
This  allows  the  user  to  determine  not  only  how  effectiveness  varies,  but  also 
why  effectiveness  varies  as  the  inputs  are  modified.  Thus,  the  model  is  a 
useful  management  tool  as  well  as  an  engineering  analytical  tool  by  providing 
data  for  trade  study  decisions,  by  tracking  system  effectiveness  during  de- 
velopment and  testing,  by  defining  sensitivities  to  threat  variations,  and 
by  providing  data  for  risk  analysis.  Figure  18  relates  the  SPEED  Model  to 
the  various  other  models  and  simulators  available  within  the  AGM-86A  Program 
Office  to  support  SCAD  development. 

3.1  MODEL  VALIDATION 

In  order  to  verify  that  the  model  indeed  provided  the  required  in- 
sight into  the  relationship  between  SCAD  design  and  penetration  effectiveness, 
an  initial  series  of  tests  were  performed  with  the  model.  The  test  conditions 
and  test  results  are  fully  described  in  Calspan  Report  No.  TA-5175-Q-11 . 
Briefly,  the  test  included  variations  in  SCAD  design,  variations  in  the  threat, 
variations  in  penetration  tactics,  and  variations  in  the  effectiveness  of 
other  penetration  aids  such  as  SRAM,  HOUND  DOG  II  and  ECM.  Analysis  of  the 
test  results  indicated  that  all  of  the  results  and  the  relative  magnitude  of 
the  variations  were  consistent  with  prior  estimates  and/or  after-the-fact 
analyses.  (Several  test  results  were  somewhat  surprising  until  subsequent 
analysis  established  that  the  results  were  indeed  consistent  with  the  test 
conditions.)  In  addition  to  providing  the  relative  magnitude  of  various  ef- 
fects, the  test  results  also  indicated  a number  of  possible  trade-offs  be- 
tween SCAD  design  and  employment  tactics  which  had  not  previously  been  iden- 


tified.  To  date,  approximately  110  sensitivity  tests  (approximately  1300 
test  runs)  have  been  performed  with  the  model. 

3.2  PLANNED  UTILIZATION 

In  order  to  minimize  the  cost  of  a program  and  to  assure  against 
large  cost  overruns  and/or  large  reductions  from  required  to  actual  perfor- 
mance, a number  of  engineering  management  procedures  have  been  instituted 
within  the  AGM-86A  Program  Office.  These  procedures  are  designed  to  detect 
SCAD  development  problems,  and  to  generate  and  evaluate  alternative  solutions. 

In  many  cases,  one  of  the  primary  evaluation  criteria  is  the  impact  of  a 
potential  decision  on  the  effectiveness  of  the  system  under  development. 

The  SPEED  model  is  an  excellent  source  of  data  for  these  evaluations. 

Over  one  hundred  runs  (of  20  to  32  replications  each)  have  been  made 
with  the  model  to  provide  data  for  the  evaluation  of  various  alternatives  by 
the  SCAD  Program  Office.  These  include  the  following  test  series:  a)  tests 

in  support  of  the  EW  Mission  Analyses  Group,  b)  SCAD  range  study,  c)  SCAD 
ECM  (Module  V)  trade  study,  and  d)  tests  to  determine  the  potential  impact 
of  EMP  exposure.  These  studies  are  discussed  in  Calspan  Rsport  No.  TA-5175-Q-24. 

3.2.1  Technical  Performance  Measurement 

One  of  the  methods  employed  to  track  the  development  of  a weapons 
system  and  to  identify  developing  problem  areas  is  Technical  Performance 
Measurement  (TPM).  Under  this  procedure,  the  performance  of  each  subsystem 
is  periodically  assessed  during  the  development  process  and  predictions  made 
concerning  the  expected  performance  of  the  production  version.  Figure  19 
provides  an  example  of  the  periodic  output  of  this  process.  In  order  to 
meaningfully  assess  the  extent  of  the  impact  of  variations  from  specifications 
as  they  are  reported,  a method  of  combining  all  the  values  of  the  parameters 
into  a single  or  small  set  of  numbers  related  to  the  effectiveness  of  the 
system  is  required.  J*0*  the  SCAD  program,  SPEED  can  accomplish  this  objective. 

By  periodically  rerunning  a specifically  selected  series  of  base  cases,  SPEED 
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outputs  can  provide  Program  Management  with  an  overview  of  trends  in  the  pro- 
gram and  the  relative  importance  of  the  various  performance  parameter  varia- 
tions. 

Figure  20  relates  the  SPEED  Model  to  the  information  flow  for  TPM. 

As  the  figure  indicates,  the  SPEED  Model  is  used  not  only  for  the  periodic 
reporting  of  the  status  (current  estimated  effectiveness)  of  the  SCAD,  but 
also  as  problems  and  trade-offs  are  identified  to  provide  data  for  making 
the  required  decisions. 


3.2.2 


Risk  Management 


A fundamental  problem  with  any  weapon  system  development  program 
is  the  assessment  and  reduction  of  the  risk  that  the  program  will  not  meet 
one  or  more  of  the  cost,  schedule,  or  performance  goals  that  are  initially 
set.  In  addition,  there  are  more  subtle  program  risks  such  as  funding  cuts, 
threat  changes,  and  program  stretchouts  that  must  be  considered.  The  TPM 
program  discussed  above  provides  some  of  the  information  required  for  risk 
assessment  and  analysis;  however,  additional  studies  and  analyses  are  also 
required. 


The  fundamental  process  within  a risk  management  program  is  the 
generation  and  analysis  of  alternatives  when  a particular  problem  arises. 
Depending  on  the  nature  of  the  problem  and  the  alternatives,  variations  in 
system  effectiveness  may  have  to  be  considered.  Figure  21  indicates  how  var- 
ious models  and  simulators  may  be  used  to  solve  a specific  (in  this  case  hy- 
pothetical) problem.  The  particular  problem  could  have  arisen  in  any  number 
of  ways.  For  instance:  1)  the  specification  value  is  unachieveable  without 

a schedule  delay,  2)  the  specification  value  is  unachievable  without  cost 
overruns,  3)  the  reduction  in  power  has  been  suggested  as  a weight  saving 
feature,  etc.  In  each  case,  however,  the  questions  represent  an  alternative 
which  has  to  be  assessed  in  terms  of  its  impact  on  SCAD  effectiveness,  as 
well  as  other  factors. 
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Figure  21  EXAMPLE  OF  USE  OF  MODELS  AND  SIMULATIONS  IN  SOLVING  A SPECIFIC  PROBLEM 


3.2.3  Other  Applications 


In  addition  to  the  above  applications  to  management  processes, 
other  applications  of  SPEED  to  the  SCAD  Program  include: 

a.  Evaluating  the  impact  on  SCAD  design  of  new  estimates  of  threat 
capabilities, 

b.  Evaluating  the  impact  on  SCAD  design  of  potential  SCAD  employ- 
ment tactics, 

c.  Examining  the  compatibility  of  SCAD  with  other  weapons  systems 
such  as  B-l, 

d.  Providing  insight  into  the  sensitivity  of  SCAD  effectiveness  to 
employment  tactics, 

e.  Providing  insight  into  the  trade-offs  between  SCAD  and  competing 
and  complementing  systems. 

3.3  APPLICABILITY  TO  OTHER  PROGRAMS 

Although  SPEED  was  designed  with  the  objective  of  evaluating  SCAD 
performance  in  a total  mission  environment,  its  applicability  is  not  limited 
to  SCAD.  For  instance,  appropriate  input  changes  could  replace  the  B-52s 
by  F-4s,  SCAD  by  RPVs,  SRAM  by  tactical  AGMs,  and  the  initially  inputted 
EOB/AOB  by  one  at  another  geographical  area. 

In  addition,  the  model  has  been  so  structured  as  to  minimize  the 
effort  involved  in  modifying  the  various  concepts  and  elements  modeled.  This 
allows  rapid  additions  or  modifications  to  be  made  when  needed  to  consider 
special  effects  of  a particular  penetration  problem. 


SECTION  IV 


MODEL  GROWTH  AREAS 

As  with  any  well  constructed  model,  provisions  have  been  made  in 
the  SPEED  model  structure  for  growth  and  modification.  To  some  extent,  pro- 
visions have  already  been  included  in  the  coding  for  expected  growth  features. 
These  provisions  were  included  although  lack  of  precise  data  precluded  com- 
plete modeling  of  specific  effects  or  features  in  the  first  version  of  the 
model.  The  model  tests  conducted  to  date  have  also  served  to  point  out  some 
areas  where  model  improvement  should  be  considered  and  other  areas  where 
model  refinements  are  not  required.  Tnis  section  discusses  some  of  the  model 
growth  areas  which  are  currently  being  considered,  and  some  of  the  modifica- 
tions which  have  been  proposed  and  analyzed  but  do  not  warrant  implementation 
at  this  time. 

4.1  PENETRATOR  CHARACTERISTICS 

The  SPEED  model  currently  considers  three  basic  types  of  penetrators: 
bombers,  decoys,  and  weapons.  Although  the  modeled  characteristics  overlap 
(i.e.,  armed  decoys  can  be  employed  as  weapons,  and  certain  weapons  can  be 
intercepted  and  killed  similar  to  bombers  or  decoys)  this  categorization  into 
three  types  is  quite  useful  from  the  standpoint  of  modeling  logic. 

4.1.1  Bomber  Characteristics 

The  following  areas  of  model  growth  in  the  area  of  bomber  charac- 
teristics have  been  or  are  being  considered:  navigation  errors,  reactive 

<<w.  react ive  flight  profiles,  turn  times  and  radii,  and  fuel  consumption 


• ntniM  use  of  the  model  is  primarily  to  simulate  that 
« flictt  where  SCAD  makes  a contribution  to  bomber 

low  rates  are  immaterial  except  from  the 


standpoint  of  defining  the  input  flight  profiles.  Thus,  calculations  of  bomber 
fuel  usage  would  not  contribute  significantly  to  currently  contemplated  anal- 
yses. Analysis  of  the  impact  of  realistic  turn  times  and  distances  (as  op- 
posed to  instantaneous  turns)  indicates  the  relatively  small  values  of  these 
parameters  will  have  no  significant  effect  on  model  results.  Thus,  revision 
of  the  currently  employed  approximation  (instantaneous  turns)  is  not  planned. 
Reactive  bomber  profiles  (i.e.,  revision  of  the  input  profiles  based  on  prob- 
able crew  decisions  given  the  current  status  of  the  penetration)  would  re- 
quire a major  rewrite  of  the  model  and  would  increase  the  running  time  con- 
siderably. Further,  the  impact  of  such  reactions  on  SCAD  effectiveness  is 
considered  to  be  minimal.  However,  reactive  bomber  ECM  is  a planned  addi- 
tion because  of  its  large  impact  on  bomber  survivability  and  its  relationship 
to  decoy  discrimination.  Bomber  navigation  errors  are  of  interest  for  two 
reasons:  1)  the  possibility  of  bomber  fratricide  if  large  numbers  of  armed 

SCADs  are  employed  and  2)  the  impact  of  mistimed  and  misplaced  SCAD  launches. 
This  feature  is  thus  planned  to  be  incorporated. 

4.1.2  Decoy  Characteristics 

Because  of  the  initial  purpose  of  the  model,  the  decoy  is,  of  course, 
extensively  modeled.  However,  two  features  not  included  in  the  initial  model 
because  of  the  lack  of  definitive  data  will  be  added:  1)  decoy  discrimination 

and  2)  alternate  decoy  launches. 

4.1.3  Weapon  Characteristics 

Currently,  most  of  the  weapons  modeled  automatically  kill  their 
targets  if  they  are  launched  and  if  they  are  not  killed  on  the  way  to  the 
target  (DGZ) . This  feature  will  be  modified  to  include  launch  and  inflight 
weapon  reliabilities,  weapon  terminal  position  errors,  and  probability  of 
kill  as  a function  of  target  type,  miss  distance,  and  weapon  yield. 
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4.2 


THREAT  AIRBORNE  INTERCEPTORS  (AIs) 


There  are  a number  of  candidate  model  modifications  in  the  area  of 
threat  AIs.  These  include: 


a)  Addition  of  AI  recycling, 

b)  Modification  of  AI  assignment/reassignment  rules, 

c)  Addition  of  AI/GCI  communications, 

d)  Modifications  of  AI  detection  modeling,  and 

e)  Modifications  of  AI  weapon  expenditure  modeling. 


Two  areas  of  AI  recycling  will  be  considered:  1)  fuel  reloading  only,  and  2) 

fuel  and  armament  reloading.  Reliability/maintainability  factors  associated 
with  recycling  are  not  planned  to  be  included.  In  conjunction  with  the  ad- 
dition of  decoy  discrimination,  the  AI  assignment  and  reassignment  rules  will 
be  modified  to  reflect  reactions  to  discrimination.  In  addition,  reassign- 
ment logic  will  be  modified  to  include  a prioritized  target  list  and  return- 
to-base.  AI/GCI  communication  will  be  added  (1)  to  model  the  effect  of  AI/ 
GCI  interchange  of  information  relative  to  decoy  discrimination  by  AIs,  and 
(2)  to  allow  the  possibility  of  AIs  providing  raid  count  data  to  the  command 
net  sites  in  an  ECM  environment.  AI  detection/search  capability  will  be  more 
extensively  modeled  to  permit  evaluation  of  the  impact  of  AI  discrimination 
and  raid  count  data.  Modeling  of  AI  weapon  expenditure  will  be  modified  to 
keep  record  of  the  remaining  weapons  load  after  each  engagement  in  order  to 
more  realistically  model  AI  recycling  and  reassignment. 

4.3  SURFACE-TO-AIR  MISSILE  (SAM)  CHARACTERISTICS 


Currently,  SAM  sites  are  considered  in  the  model  to  operate  inde- 
pendently of  each  other  and  of  the  EW/GCI/AI  network.  Analysis  of  model  re- 
sults to  date  indicate  that  the  required  SAM  netting  and  control  logic  in 
the  model  would  not  contribute  significantly  to  model  results  but  would  sig- 
nificantly increase  model  complexity:  therefore,  this  modification  is  not 

planned.  However,  minor  modifications  of  the  treatment  of  such  factors  as 
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time  between  salvos  and  missile  inventory  is  contemplated. 


4.4  DEFENSE  EW/AEW/GCI  NETWORK 

Three  areas  of  modification  and/or  growth  are  currently  under  inves- 
tigation relative  to  defense  netting.  These  are:  1)  net  reaction  to  decoy 

discrimination,  2)  interfaces  (i.e.,  track  handover  and  communications),  and 
3)  expanded  ECM  effects  on  the  net.  Provisions  for  the  first  item  have  re- 
cently been  incorporated;  however,  specific  requirements  have  not  yet  been 
determined.  The  network  interfaces  are,  of  course,  currently  modeled  but 
continuing  analyses  are  being  conducted  to  determine  what  further  refine- 
ments are  desirable.  Specific  modifications  to  include  more  sophisticated 
treatment  of  ECM  have  not  yet  been  defined.  Such  effects  as  multiple  targets 
per  strobe,  ghosts,  false  targets,  and  cumulative  noise  are  under  considera- 
tion. 

4.5  OTHER  MODIFICATIONS 

A continuing  effort  is  planned  to  improve  the  model  in  terms  of 
use-oriented  features.  This  effort  will  concentrate  on  reducing  running  time, 
providing  additional  useful  outputs,  improving  output  formats,  and  minimizing 
input  complications.  In  conjunction  with  this  effort,  a continuing  task  will 
be  the  updating  of  the  user  and  programmer  manuals. 


